In many cases, data packets need to be sent over a communication network between a user equipment and a further entity. Transmissions can be performed both in downlink and uplink direction and the further entity is often another user equipment, e.g. in a telephone call. The further entity may also be a service entity like a server which may send different packet flows for sound and video to the user equipment, e.g. in a streaming session, while the user equipment may also send packets to the further entity. The further entity can either be part of the communication network or it is able to exchange data packets with the network.
The communication network can be a fixed or a mobile network. More than one network can be involved in the transmission, e.g. if the user equipment is located in a mobile network which is interfacing directly or via intermediate networks to a fixed network in which the further entity is located. Customary mobile networks comprise a core network with core network nodes, e.g. general packet radio service support nodes (GSN) like a serving general packet radio service support node (SGSN) or a gateway general packet radio service support node (GGSN). The core network nodes allow the exchange of data with external networks such as the Internet or mobile or fixed networks of other operators. Furthermore, customary mobile networks comprise one or more access networks with access network nodes for controlling the radio transmission to user equipment, commonly designated, e.g., as base station controllers, radio network controllers (RNC), Node B or base transceiver stations. Other implementations of the nodes and networks are possible, for example an enhanced GSN and an enhanced RNC which perform different parts of the SGSN functionality and thus allow omitting an SGSN.
An operator may offer services to the subscribers that generate different types of packet traffic, which are all transmitted over the communication network. Depending on the type of packet traffic, the requirements for the transmission differ significantly. For example, voice transmission requires low delay and jitter while a limited amount of errors can be acceptable. Streaming sessions using packet buffers typically allow higher delays and jitter and the receiver can generally also correct or hide errors. File transfer can often be performed as best-effort traffic but normally requires error-free data. In addition, operators may choose to offer different qualities of service (QoS) depending on the user subscription, i.e. they may choose to perform user differentiation. Accordingly, the provision of a defined quality of service is an important concept in the control of data traffic as described for example in technical specification 3GPP 23.107 V 6.3.0. of the 3rd Generation Partnership Project “Quality of Service (QoS) concept and architecture”.
Different contexts define the quality of service relating to a data transmission involving nodes of a communication network and the user equipment. The user equipment and a core network node negotiate a PDP (Packet Data Protocol) context which specifies parameters for the transmission of data packets to and from the user equipment over a 3GPP bearer. Further contexts can be set up for bearers relating to different links between the further entity and the user equipment, e.g. a context for the radio bearer between an access node and the user equipment, which specifies the transmission parameters on the radio link. Packet flows between the further entity and the user equipment are then mapped to bearers associated with these contexts and forwarded accordingly.
Current 3GPP standards define a mechanism to map downlink data to a packet bearer. For this purpose, the bearer is associated with a PDP context. The PDP context is the granularity with which QoS can be provided, i.e. different PDP contexts can provide a different QoS. The mapping of packets onto PDP contexts is done in an edge node of the communication network, e.g. in the GGSN using downlink Traffic Flow Templates (TFT). A TFT is a packet filter which defines rules that uniquely map incoming data packets onto a PDP context. The downlink TFT is part of the PDP context definition and can be configured to operate on a number of different parameters. For example, the IP source address of a data packet or the “Type of Service”-field (ToS) in the IP-header can be used to map packets onto a PDP context. The Session Management (SM) protocol is used to manage PDP Contexts.
In the uplink, the user equipment requires information how to map data packets from an application to a bearer with the associated context. However, this functionality is not in the scope of the current 3GPP standards. Instead, it is defined proprietarily and can differ between vendors of user equipment. In one implementation, the user equipment has several PDP context templates, each with a different associated QoS. A connection manager provides a mapping for each application to one of the PDP context templates. The mapping is a static configuration which creates a binding in the connection manager and which is signaled to the user equipment, e.g. by an SMS. Typically, the user performs the configuration by visiting the web-site of an operator and entering the phone model he is using and which application he wants to configure, e.g. WAP or MMS. Upon initiation of a session, e.g., when making a call, the application communicates to the connection manager through a proprietary API (Application Programming Interface). The connection manager associates the data packets from the application with the configured PDP context and, if required, sets up the context. Correspondingly, there is a static binding between application and PDP context template. The identifiers and formats used in the configuration can be specific for each vendor.
As a result, the existing methods for associating data packets with a bearer are inflexible and do not allow dynamic changes of the configuration. A further problem is that application development is both access specific and vendor specific, i.e. applications must be written for a specific access (e.g. 3GPP) and a particular vendor of user equipment because the QoS API in the above binding mechanism may differ for both vendor and access.
Furthermore, user equipment according to 3GPP specifications may consist of two entities, a terminal equipment (TE) and a mobile terminal (MT) which are logically and optionally also physically distinct. Applications are executed in the terminal equipment and data packets are exchanged over the mobile terminal with the mobile network. In the state of the art, an interface between TE and MT would be required over which it is possible to convey the bearer requirements of the application. As the binding of application and context is vendor specific in present user equipment, different interfaces would be required. If the terminal equipment is for example a personal computer and the mobile terminal is a mobile network card, the computer may need to support different interfaces for different card vendors, leading to high complexity and cost.